Lock built-in JavaScript runtimes - #33
Conversation
|
Thanks for working on this! One concern before merging: these lockfiles are tied to Previously, those dependencies were resolved using the project’s configured registry. Could we fall back to normal resolution when the bundled lockfile’s registry policy is incompatible? |
|
Thanks, good catch. I pushed 84ffe3c to address this.
This fallback is scoped to bundled package sets. Generic explicit lockfile validation in Added a regression test covering an incompatible private-registry policy. Validation:
The default compatible-policy path still installs the packaged locks without re-resolving. |
2 participants
Summary
npm_exlockfiles for the built-in Svelte, Solid, and Tailwind runtimesVolt.JS.Runtime.PackageSetProblem
Volt's built-in framework/compiler runtimes currently resolve version ranges independently of an application's
package.jsonandnpm.lock. For example, the Svelte plugin requests^5.0.0, while Tailwind requests^4.3.0and*. The runtime installer already supports a package-owned lockfile, but these built-in callers do not pass one, so a fresh build can select a different transitive graph without an application lockfile change.Design
Volt.JS.Runtime.PackageSetkeeps each built-in runtime's exact package set and packaged lockfile together. Both direct installation and named runtime creation use that same lock. Named runtime signatures hash the lock contents rather than depending on a path, so changing a packaged graph cannot silently reuse a runtime created from an older lock.scripts/update_runtime_locks.exsregenerates all locks, or one selected package set with--only, from the exact versions declared by the owning module.Verification
mix test: 609 tests, 0 failurespriv/npm/{svelte,solid,tailwind}.lockamd64consumer builds produced identical runtime locks and production assets